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A METHOD AND AN APPARATUS FOR A UNIVERSAL TRADING 
MARKET DESIGN AND DEPLOYMENT SYSTEM 

Cross-Reference to Related Application 

The present application is a Continuation-In-Pait of co-pending 
• application serial no. 09/131,048 filed August 7, 1998 by appUcant Yoav Shoham 
et al„ entitled "A Universal On-Line Trading Market Design And Deployment 
System." 

FIELD OF THE INVENTION 

The present invention relates to the use of networked computer systems 
for the design and deployment of a trading market. More specifically, the 
invention relates to an auction engine organized around modular components 
representing dimensions of auction specifications. 

BACKGROUND OF THE INVENTION 

Simple auctions that do not require complex computations are currently 
prevalent on the Intemet. Onsale.com, eBay.com, and Priceline.com are 
representative of such auctions. Onsale, Inc. and Priceline, Inc. used customized 
software specific to their particular auction mles. This software is not easily 
modified or deployed m a different business context. 

Toolkits embodied in software offered by Opensite and Bonsai may be 
used to construct and operate simple auctions. But customization of an auction by 
these tool kits is limited. For example, a maricet designer may specify the 
duration of the auction or select a simple auction format; however, other variables 
in establishing an auction may not be modified without significant labor. 
Although IBM has developed an auction toolkit that allows a somewhat greater 
degree of customization of an auction through subclassing of elements from a 
library of software objects, it is not a comprehensive market design and 
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deployment system. Additionally, this system is limited to single-unit buyer-only 
auctions. 

Moai, Inc. (Moai) has software that typifies products that are not auction 
products; rather, Moai provides software solutions that embody auction 
technology. Moai builds software for creating Internet auctioning solutions for 
manufacturers or resellers to sell surplus-goods and excess inventories. Although 
Moai's software solution may be tailored to meet the needs of a customer, the 
auction style and mechanism are linuted to a specific auction type. 

The Michigan Internet AuctionBot, another Internet service, allows a party 
to create and manage an auction (e.g., accept bids, notify bidders of auction 
results, etc). Although AuctionBot supports a broader set of auctions than otiier 
services, it has linutations. In particular, AuctionBot cannot support activity rules 
of the sort encountered in industrial markets such as the FCC spectrum auction 
and the California Power Exchange. Nor does it provide a modular architecture 
for extending the range of configurability of the system. 

In sum, a market designer of an Internet auction has two options-develop 
software or use limited toolkits. Therefore, it is desirable to have a means witii 
which to define and deploy a wide range of Internet auction markets without 
engaging in lengthy software development. 

SUMMARY OF THE INVENTION 
Methods and apparatuses for designing and deploying an interactive, real- 
time, universal trading market system on the Internet are disclosed. One 
embodiment of tiie invention relates to a universal auction specification system 
having a programmable auction server. The progranmiable auction server has a 
plurality of auction specification modules wherein at least one auction 
specification module corresponds to at least one function of an auction variable 
selected from the group consisting of a process bid, release information, and a 
clear. 
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Other aspects and methods of the present invention, as well as apparatuses 
formed using these methods, are described further below in conjunction with the 
following figures. 

BRffiF DESCRIPnON OP THE DRAWINGS 
Figure 1 A is a system block diagram showmg the components of the 
preferred embodiment. 

Figure IB is a diagram showing the programmable auction server of the 

system. 

Figures 2 and 3 schematically show one embodiment of the invention 
wherein a bid is received and is verified. 

Figure 4 shows data flow of one embodhnent of the invention. 

Figure 5 illustrates a three-tier specific embodiment of the present 
invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

Methods and apparatuses are disclosed for designing and deploying a 

universal, interactive, real-time, trading market system serving traders 

conununicating through the Internet and similar networks. This generic system 

for specifying and deploying trading market systems such as auctions is novel 

over the limited systems known in the art One embodiment of the invention 

relates to a universal auction specification system having a programmable auction 

server (PAS). The progranmaable auction server has a plurality of auction 

specification modules wherein at least one auction specification module 

corresponds to at least one of the following auction functions: processing a bid, 

releasing auction information, and clearing the auction. 

In the following detailed description, numerous specific details are set 

forth in order to provide a thorough understanding of the present invention. It 

will be evident, however, to one of ordinary skill in the art that the present 
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invention may be practiced without these specific details. In other instances, well 
known structures and devices are shown in block diagram form in order to avoid 
unnecessarily obscuring the present invention. 

Figures lA through IB show various embodiments of the invention in 
which a universal auction specification system of the invention may include a 
variety of components such as a Market Specification Console ("MSC) 1 10, a 
Universal Trading Console ("UTC") 120, a Universal Surveillance Console 
("USC") 130, a Market Administration Console ("MAC") 150, PAS 140. and a 
communication network 160 and 161 linking various components. These 
components may be stored or operated in a single computer system or in a 
plurality of computer systems cormectcd by a network. 

Overview of System Modules 

MSC 1 10 consists of a computer running a computer program in which a 
market designer may specify any of an infinite number of possible market 
protocols. Thereafter, the market defined by market protocols is submitted or 
uploaded to a PAS 140 for execution. Markets may be as simple as English or 
Dutch auctions with some parameters designated by a market designer. 
Alternatively, a market designer may develop an arbitrary auction tiiat uses very 
complex computations. 

Although markets may be organized in various ways, markets generally 
consist of a sequence of phases. Each phase comprises an interval(s) wherein 
an activity is governed by a relatively fixed set of rules specified by the market 
designer. The temporal flow of a market consists of a series of market phases 
specified by the market designer. In order to specify this temporal flow, the 
market designer must identify the phases. Phases are identified and sequencing 
relations (e.g., termination conditions, conditional branching among the phases, 
etc.) are designated by manipulating representations of the phases on the 
Graphical User Interface (GUI) of the MSC 1 10. A phase may be defined by a ' 
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time period, a limitation, a condition {e.g. condition precedent, condition 
concurrent, condition subsequent, etc.)» exception, exclusion, or a proviso etc. 
The market designer may designate criteria such as when the phase terminates 
(e.g., a specified time period, condition such as the first one hundred bids 
received, etc.), the method to choose a succeeding phase (if any), and any other 
applicable limitations. 

In order to specify rules such as market rules governing a particular 
phase, the market designer selects options - referred to herein as trading 
primitives ("TPs") - that dictate the behavior of components in the PAS 140. 
MSG 1 10 pix)vides menus and other means for choosing options and may 
provide guidance to the market designer regardmg legal combinations of these 
options, or recommend choices associated with specified design goals* 

UTC 120 consists of a computer running a computer program that enables 
a trader {e.g., seller, buyer, agent of a seller or buyer) to trade in any market 
protocol executing on the PAS 140. UTC 120 presents information to the trader 
in a manner that automatically adapts to a specific market protocol that is 
executing. 

use 130 consists of a computer miming a computer program that enables 
a surveillance body such as a regulatory agency or an independent audit firm to 
monitor the operation of the markets executing on the PAS 140. This function 
allows the surveillance body to determine whether the execution of an auction 
conforms to norms and, optionally, to intervene in the market when deviations are 
detected. 

MAC 150 consists of a computer running a computer program that 
enables a market operator, an entity housing the PAS 140 and responsible for ; 
the operation of the PAS, to monitor the execution of various markets 
operating on the PAS 140. MAC 150 also administers registration 
transactions, such as the process whereby traders identify themselves to the 
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system (e.g., providing their names and credentials). Additionally, MAC 150 
allows market operators to troubleshoot the system in real time. 

PAS 140 mcludes a computer that runs a computer program that may 
accept multiple niarket protocols submitted to it from an MSG 1 10 and execute 
multiple market protocols {e.g., opening auctions, admitting or rejecting bids, 
clearing prices, notifying traders of market events, and closing auctions). More 
specifically, PAS 140 enoploys several modules to control the market operation. 
Modules such as bid verifier, release information manager, and clearer assist in 
managing the market by processing incoming bids, responding to quraes, 
maintaining market state (e.g., tracking bids, etc.), and reporting results to 
traders and optionally to non-traders. Through these modules, various 
transactions may be performed such as bid verification (e.g. does a bid from a 
trader qualify as a "bid" under the rules), release of information (e.g., show all 
the current bids), a clear (e.g. clear the prices or bids), registration of 
information (e.g. name and phone number of the trader), and a bid 
transformation. In the preferred embodiment, various components are 
organized into a complete system through a 3-tier architecture bounded by 
double firewalls 164 as shown in Figure lA. 
The Market Specification Console (MSO 

MSG 1 10 makes available to a market designer a full spectrum of rules for 
defining market protocols in an intuitive fashion. These mles may be modified by 
the market designer. Combinations of rules for participating in and operating a 
market constitute market protocols. Maricet protocols specifiable through MSG 
range from simple auctions such as EngUsh, Dutch, and sealed-bid auctions, to 
highly complex auctions such as those conducted on the trading floors of financial 
exchanges and the California Power Exchange. 

Table 1 provides examples of some types of auctions that could be 
specified through MSG 1 10 for deployment in PAS 140. As shown below, 
auction types may be arranged in a hierarchy, which the market designer would 
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use as part of the market specification process. Note that the partial hierarchy 
depicted is but one of many possible arrangements. 

Table 1: Example of Auction Classifications 



1) 


Single good type 




a) One-sided (e.g., only buyers bid) 




i) English (ascending price) 




ii) Dutch (descending price) 




iii) Sealed-bid 




b) Two-sided (buyers and sellers bid) 




i) Continuous double auction 




ii) Call market 


2) 


Multiple good types 




a) Simultaneous ascending price 




b) Combinatorial (bundle bidding) 



Table 1 shows multiple classes of auctions. The table includes auctions ' 
for one good or multiple goods. Smgle goods may be auctioned by one-sided or 
two-sided auctions. Among the types of one-sided auction are English, Dutch, and 
sealed-bid auctions. The English auction (in the case where buyers bid) operates 
in the typical fashion wherein Trader A makes a bid on a good. Trader B would 
then make a bid that is higher than the bid submitted by Trader A. The highest 
bidder prevails in the buy-side English auction. In a buy-side Dutch auction, on 
the other hand, prices start at a high level and decrease until a trader submits a 
bid. The sealed-bid auction involves collects bids from traders and withholds 
information until the end. At clearing time, the best bids prevail. 

Two-sided auctions represent another class of auction. In two-sided 
auctions, both buyers and sellers submit bids. One example of this class is the 
continuous double auction. A continuous double auction collects offers from 
buyers and sellers. If an offer to buy and an offer to sell match, a trade is 
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consummated. A call market operates similarly, except that bids are aggregated 
over time, and matched in a periodic manner. Trades typically occur at a uniform 
price consistent with all of the matched bids. 

As noted above, multiple goods may be auctioned. This involves multiple 
goods offered by a single company, a government agency, or some other entity. 
Simultaneous ascending price auctions involve multiple ongoing auctions for 
different goods. Combinatorial (bundle bidding) auctions involve traders bidding 
for combinations goods such as a trader submitting bids for the bundle consisting 
of good A, good B, and good C- 

Generally, a market designer may define a market in one of two ways. 
One method is to select a market protocol that has been predefined in 
parameterized form, and input the values of its ftee parameters. For example, a 
market designer may specify the minimum increment and start time in an English 
auction. The other method is to allow a market designer to define arbitrary 
market protocols suited to any given situation. 

Although the number of market protocols is limitless, some universal 
principles apply. First, every auction is associated with a set of entities that are 
allowed to participate, called traders. Traders participate in markets by 
submitting bids, which are offers to buy or sell the auction's goods at specified 
terms {e.g., prices and quantities dictated in the bid). As a result of the bids, some 
information may be released to traders about a market's status. Under conditions 
specified in the market protocol, the auction clears and die resulting exchanges 
are determined. The auction closes when a termination condition is met. 

Because of these uiuversal elements, it is possible to define TPs that 
represent particular choices for features of a market protocol, applicable across a 
range of auction types. For example, one TP might specify whether an auction is 
one-sided (e.g., buyer or seller bid), two-sided (e.g., buyer and seller bid), a 
sealed-bid or "open outcry" {e.g., bids are exposed to all traders). TPs may also 
dictate when important events, such as clears or information releases, are to 
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occur. Further examples of TPs and how they are used to specify auction 
behavior are presented in the section describing the PAS 140 below. 

Each phase of an auction is thus defined by specifying the TPs it 
comprisesorthetinoelinefor application of the TPs. One general method of 
specifying a time line is to invoke a scripting language that has control constructs 
for sequencing and iteration, access to internal auction events and a time-of-day 
clock, and the capability to call the TPs. This role may be filled by a specially 
designed auction scripting language, a standard scripting language such as 
TCL/TK, JavaScript, a full-fledged programming language such as Java, any 
other scripting, or any programming languages. The preferred embodiment of the 
invention utilizes a script generator 121 to generate scripts in a language 
generically referred to as CommerceScript. CommerceScript is a temporal 
protocol script that represents an auction specification. 

The temporal nature of CommerceScript provides an additional level of 
convenience in market specification. Rather than restrict the market designer to 
textual scripting, the invention presents to the market designer a visual scripting 
option. This visual scriptmg option allows the market designer to graphically 
draw a time line and place along the time Ime various TPs. Each TP may be 
annotated with a variety of information such as the market entity executing the 
TP, whether this execution is mandatory or permissible, whether conditions must 
precede or occur after this step and temporal preconditions that must be met. The 
output of the visual specification component is siniilar to that of a textual 
specification component Although various visual progranuxung tools exift in the 
art, such tools have not been applied to the creation of a trading market 
specification. One novel aspect of the visual specification component annotation 
involves processing steps as "mandatory" or "permissible," which is uruque to the 
commercial application. 
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The Programmable Auction Server (PAS) 

PAS 140 is extensible and flexible. PAS comprises an interpreter for 
CommerceScript, and modules implementing the behaviors dictated by the TPs 
referenced in the script. In principle, there is no bound on the range of allowable 
market protocols, other than the pragmatic limitations of the PAS 140 in terms of 
computer memory and other computational resources. 

A market protocol may accord to distinct market entities various 
permissions to perform activities such as bidding in certain ways or retrieving 
certain forms of information. Such permissions are based on registered trader and 
auction attributes as captured by the MAC 150 registration process. One feature 
of the PAS 140 is its generic way of handling permissions regardless of the 
particular market protocol that is executed. Each step in the execution of the 
protocol is gated by the type of market activity, its particular instantiation (i.e., the 
value of specified inputs), and the entity attempting to execute it. Flexibility 
permission management offered by the invention is important in industrial 
applications that generally require security measures such as defenses against 
malicious infiltrators and incompetent market entities. 

To promote fault tolerance, the PAS 140 creates an audit trail by loggmg 
every activity that takes place on the system, including bids, other trader actions, 
market clear results, and other similar actions. In addition, a trade management 
module records trades and the obligations incurred by each participant For 
example, the trade management module may record that Trader A, a buyer, 
submitted a bid of $100 for a good such as a book. Because this bid reflects the 
highest bid received, Seller B sold his book for $100 to buyer A. Trade 
management module will record that buyer A is obligated to pay Seller B $100 in 
exchange for Seller B's book. 

PAS 140 is comprised of several modules that may be added or 
customized for different market protocols. These modules, discussed below. 
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implement market functions based on TPs specified by the market designer. PAS 
140 uses script interpreter 141 to execute the market protocol, and provides 
application program interface 510 and proxy bidder 509 for extensibility and 
cotmection with other auction system components. 

1. Script Interpreter 

PAS 140 uses a generic script interpreter 141 that is capable of 
recognizing and interpreting ConmierceScript, other type of script, or any 
programming language. Additionally, script interpreter 141 may be modified to 
adapt to new scripting languages. 

2. Bid Verifier 

Bid verifier 151 tests each incoming bid for consistency with the bidding 
rules established by a market designer. A "bid" is defined as an expression of an 
action that may modify a bid state. Bids mcLude a variety of actions such as a 
buyer indicating a willingness to purchase a good at a certain price, or a 
withdrawal of a previous bid. Changing a bid qualifies as a new bid. If verified 
as an eligible bid, the bid is admitted to an order book; otherwise, the bid is 
rejected. There are many possible varieties of bidding rules diat may be specified 
in TPs through the MSG 110. Examples of bidding rules provided below are for 
illustrative purposes otdy. 

In one embodiment, bid verifier 151 operates such that the incoming bid is 
compared to a bid referred to as a base bid. The base bid may refer to the trader's 
own bid, to all bids, or to some summary {e.g.y a price quote), as determined 
through applying the bid rales. For example, assume a bidding rule requires that 
in order for a bid to be eligible, a bid must meet the following requirement: 

bid* highest bid received + X 
wherein x equals $20 and the highest bid received is assumed to be $100 and it is 
the highest bid received for that auction at a certain period of time. The highest 
bid represents the base bid. In this example, the base bid is replaced with a higher 
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bid. The higher bid is then refened to as the base bid. The incoming bid must be 
at least $120 to be entered into the order book. 

Another example of a bidding rule may restrict the type of traders who are 
eligible to bid or it may restrict the bids that different traders may submit. 
Bidding rules may also regulate whether withdrawals or replacement of a bid are 
allowed. Limits may also be placed on the frequency of such actions, or of bids in 
general. Any bidding rule may be designated by a market designer to apply over 
the entire course of the auction or for designated periods {e,g,, stages or rounds). 
Dynamic biddmg rules based upon bid content may also be used. For example, 
ascending (or descending) restrictions dictate that replacement bids must exceed 
or be exceeded by some base bid, as discussed above. These restrictions may 
apply to only one side of a trade or to both buying or selling. 

In other ways, bidding rules may serve to define what offers are 
expressible. For example, they can designate whether bids may refer to oidy a 
smgle unit of a good versus allowing bids for multiple units. Additionally, if 
multiple units are allowed, the bidding rules may designate that offers may 
include single price points, multiple price points, or only quantities at a given 
price. Other examples of expressivity restrictions include discrete offers versus 
continuous offers, price-quantity monotonicity, divisibility (all-or-none bidding), 
interpolations/extrapolations, etc. 

Expressible bid conditions also may be used in biddmg rules to restrict 
bids in an auction. For example, expressible bid conditions include minimum 
quantities of a good to be bid upon or a minimum bid amount that must be 
satisfied. In regard to multi-dimensional auctions, combinations may be deemed 
permissible in bundles. "Portfolio" bidding may also be acceptable. Maxunal 
complexity of bundle constraint specification may also be included. 

Bidding rules regarding eligibility also may be specified. Eligibility of "ia 
trader or a particular bid may be specified in a variety of ways. For example, the 
eligibility of a trader or a bid may be specified in terms of previous auction 
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history, including the history of auctions distinct from but related to the auction in 
question. This is typically the case for restrictions referred to as activity rules that 
are common in complex auction scenarios. 

Bidding rules may also involve payments, such as a fee paid in order to 
allow a participant to engage in trading. For example, an initial bid may require 
an entry fee (refundable or not refundable), or withdrawals may be allowed on 
payment of a deconomitment penalty. The foregoing represents a portion of 
bidding rules that may be used in an auction. By executing of bidding rales such 
as those presented above, a 'T)id state" is created. A "bid state" is the status of the 
bids bom the various traders. The status of bids is maintained in a fashion that is 
known in the art. A bid state also may include historical data of the various bids. 
For example, a graphical representation of bids may be displayed to traders on a 
trade interface displayed to traders. Through the trader interface, a trader is 
capable of inputting and receiving information from the universal auction system. 
Information may be communicated to the universal auction system through a 
keyboard, a touch screen display, or voice activated system. 

3. Bid Transformer 

A bid transformer 155 implements discriminating allocation maricet 
protocols that may produce different effective prices. Discriminating allocation 
market protocols may be based upon the identity of the trader ("trader identity") 
submitting the bid, the quantities allocated to a trader identity, or any other 
condition that the market designer designates. Trader identity may be associated 
with individual traders or established groups (e.g., certified dealers, registered 
clients, holders of particular credit ratmgs). 

In the preferred embodiment, each submitted bid is subjected to a bid 
transformer 155 that applies a discriminating policy to a bid. For example, if a 
particular trader such as Trader A is entitled to a discount of 20%. its offered 
price is increased by an amount such that reduction by 20% equals the original 
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bid. Accordingly, a bid of $10 by Trader A is transformed to $12.50. This 
transformed bid of $12.50 is then compared to the bids received by other traders. 

Another example relates to offered prices for quantities of goods (or 
services such as amounts of specified tasks) above a certain threshold amount. 
Quantities of goods may be assessed a **penalty" percentage to bias the allocation 
toward a trader(s). After the bids are transformed by bid transformer 155, the 
transformed bids are sent to the bid verifier 15L 
One alternative method to the preferred method involves implementing a 
discriminating allocation policy using the clearer 154. In this approach, bids are 
not transformed. Instead, the clearing calculation is modified to implement the 
discriminating allocation policy. For example, if the discriminating allocation 
policy dictates that no trader should receive more than half of the allocated 
quantity, the clearing algorithm would maxunize its objective measure subject to 
the constraint that this quota is not exceeded. 

4. Information Manager 

Information manager 152 controls the information released by the auction 
to participants diiring the course of bidding. In effect, it dictates the class of 
queries regarding bid state and bidding and trading history that an auction may 
handle. Unhandled queries produce null responses. 

Mechanisms may distinguish between information available through 
active and passive means. Traders may actively request released information 
through explicit queries. Information is released to passive access by defining a 
price quote operation. A price quote is a particular form of auction status 
summary that typically specifies a result of a hypothetical clear, but may also 
specify any other salient information (e.g., the highest buy bid received). A price 
quote may be computed at a release time and cached so that information may be 
made available without querying and explicit queries do not induce a complex 
calculation. For single-good auctions, one form of price quote is a "bid-ask 
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spread" that may degenerate into a single price. A bid quote represents a price at 
or below which an agent would have to offer to sell in order to successfully sell 
(assuming no other changes occur to the auction state). An ask quote represents a 
corresponding price with respect to an ask quote. Auctions may define multiple 
price quote operations to be employed in different situations or for different 
classes of traders, where class may be characterized in terms of trader identity or 
bid status. 

The market designer defines the behavior of information manager 152 by 
selecting TPs (through MSG 1 10) specifying the content and timing of price 
quotes, as well as the class of explicit queries to be handled. like other auction 
events, information releases may be timed according to fixed schedules or by 
events (e,g. clears, bids, inactivity intervals, etc.) 

In addition to the bid state as reflected in the order book 1S4, the 
information manager 152 may also control release of other relevant auction state 
information. For example, the auction state may include the eligibility of traders 
to make additional bids, or other market information that may affect trader's 
expectations. 

The information release policy implemented by information manager 152 
can have a significant influence on the nature of the auction. Moreover, at one 
extreme, all information about the bid state information may be revealed, as in an 
outcry auction. However, at the other extreme, if a sealed-bid auction is used, no 
information is revealed about other traders' bids. 

5. Order Book/Clearer 

Order Book/Clearer 154 ("clearer") determines an allocation of goods and 
terms of exchange on the basis of bidding history and auction mles. An 
allocation typically corresponds to a set of trades among the auction participants. 
Once the trades are determined, it reports the results to traders and, optionally, 
non-traders. Clearer 154 uses the bid state as represented by the order book to ' 
derive the exchanges determined by auction rules in a given state. It may also 
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invoke a trade manager module to control the notification and execution of these 
trades. 

Clearer 154 is invoked according to the temporal flow TPs specified in the 
MSG. Other TPs dictate how it determines an allocation. An allocation policy 
may be specified by naming the algorithm implementing the function from the 
auction state to allocations, or by defining a complete set of criteria for selecting 
among the possible allocations (e.^., allocations consistent with the offers 
represented by bids). 

Clearer 154 may use a general class of allocation policies that may be 
defined by interpreting the offers specified in bids as if they represent value 
functions, and maximizing the resultmg surplus. However, this maximization is 
generally not unique because monetary transfers are zero-sum operations. Thus, 
the rules may need to specify how to allocate surplus among traders. For 
example, in a sealed-bid auction of a smgle unit of a good, the Ist-price auction 
maximizes total surplus and then allocates as much as possible to the seller. The 
2nd-price auction allocates as much of the surplus to buyers. A k-double auction 
may divide this surplus fractionally according to parameter k. Typically, even 
these rules are not unambiguous, since there may be a choice among buyers (or 
sellers) to allocate a positive surplus. Methods for choosing among surplus- 
equivalent bids might be based on features such as dme of bid, quantities, or even 
random selection. Such criteria are often referred to as tie-breaking rules. 

Qearer 154 may use another type of clearing policy that determines 
exchanges based upon chronological priority. For example, the continuous 
double auction ("CDA") matches buyers and sellers instantaneously upon 
receiving compatible offers. The release of information about the exchange may 
be delayed. In contrast, a call market aggregates bids over time before 
determining an allocation. As the clearing interval of a call market is reduced, an 
approximate CDA is determined. 



16 



wo 00/08578 



PCT/US99/17248 



Clearer 154 may use discriminatory or non-uniform-price auctions that 
may allocate identical goods to traders at different prices. For example, in pay- 
your-bid auctions, successful traders on one side exchange for exactly the amount 
they bid, regardless of terms for other successful traders. 

Regardless of the allocation policy specified, the invention is capable of 
realizing each by allowing a market designer to specify an available TP or 
integrate an entirely new component into PAS 140 to supplement the policy, 

6. Proxy Bidder 

Bids submitted by a trader may be entered by direct bidding or proxy 
biddmg. In direct bidding, the bidder selects an auction and enters a bid using the 
computer keyboard and mouse (interface provided by UTC 120). In proxy 
bidding, the user defines a script that bids on his or her behalf in one or more 
auctions runnmg on the PAS 140. As part of the proxy bid, a trader also specifies 
whether the script is to run within the trader console UTC 120 {e.g., proxy bidder 
508), or be transmitted to the PAS 140 and run there (e.g., proxy bidder 509). 

The proxy bidder 509 may be further optimized to exploit the fact that it is 
running within the PAS. Specifically, when there are proxy bids from multiple 
traders, the proxy bidder 509 may resolve the competition among these bids 
direcdy, avoiding the need to iteratively submit progressively increasing bids to 
the order book. 

7. A pplication Program Interfaces 

PAS 140 has a set of Application Program Interfaces ("APIs'*) 5 10 that 
provide a means for extending the PAS to incorporate replacement or additional 
modules. The purpose of the APIs is to turn a closed system to an open system. 
A closed system requires tiiat the system be used in total or forego usmg the 
closed system. In an open system, components may be integrated seamlessly with 
existing components. For example, APIs allow integration of PAS 140 with (1) 
legacy software for registration or transaction management; (2) auditing ot 
monitoring functions of accreditation agencies, (3) programs implementing novel 
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clearing algorithms, and (4) programs perforaiing trades which bypass the UTC 
120 discussed below. 

The Universal Trading Console fUTC) 

The UTC 120 has at least two fimctions-display of information and bid 
mput. Examples of information displayed to a user include activities on the PAS 
140 and ancillary information. PAS 140 activities are, in principle, events logged 
by the PAS 140, such as the start of an auction, the bids placed, and the prices 
cleared. Actual information displayed may vary from one market to another, 
reflecting the different market designs. In particular, the amount of information 
displayed may vary. For example, two simultaneous ascending-bid auctions may 
vary the information disclosure policy with one auction releasing information 
after each roimd such as the entire list of bidders and tiieir bid in that round, 
whereas another auction may release only the aggregate bids supplied with no 
bidder-specific information. Ancillary information may be any information that is 
relevant to making trade decisions but that is not inherent in the market activity. 
For example, in energy markets and many other futures markets weather forecasts 
may be important information to a trader. 

Diversity exists in the format of both the information dissemination and 
the bid collection among different types of auctions. In the preferred 
embodiment, this diversity is acconmiodated by introducing a database layer 
between the PAS 140 and the UTC 120. For each auction type, several specific 
database schemas must be introduced. The PAS 140 populates the database vjith 
specific data and that data is displayed in the UTC 120 automatically using 
dynamic HTML. A feature of this design is that while the database tables in the 
PAS 140 must be created for the particular auction, tiie UTC 120 requires no 
modification. 

Figures 2 and 3 schematically show one embodiment of the invention in 
which several of the modules are shown. Here, a bid (e,g. $100) is submitted by 
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Trader A at operation 600. The bid is sent to the bid verifier 15 1 at operation 
610. Bid verifier 151 receives the bid and uses the bid by incorporating the bid in 
the TPs set by the market designer. At operation 610, the bid verifier detennines 
whether the bid is acceptable. If the bid satisfies the minimum standards for an 
acceptable bid established by the market designer, the bid is verified as an 
acceptable bid and is placed into the order book/clearer 154 at operation 640. If 
the bid fails to meet these minimum standards, the bid is rejected and Trader A is 
notified that his bid is unacceptable, Infonnation manager 152 notifies Trader A 
by transmitting the rejection to Trader A at operation 625. Similarly, proxy bidder 
509 may also submit a bid to the bid verifier 151. This bid undergoes the same 
process as listed above. The trader(s) who submitted the proxy bid is notified 
through the information manager 152 as to whether the proxy bid is acceptable or 
is unacceptable. 

The Universal Surveillance Console fUSQ 

Professional trading markets are generally associated with one or more 
surveillance bodies such as the SEC, the FCC, FERC, California Public Utility 
Commission (CPUC), internal monitoring departments of exchanges, and external . 
private audit agencies* A surveillance body monitors trading activities and 
ensures that trading activities comply with specified standards. Monitoring is 
essential to ensure that traders comply with laws or rules. Compliance with rules 
promotes faith in the market. USC 130 presents information from the 
marketplace to a surveillance agency. While the USC 130 does not provide ways 
in which to trade in the market, it does provide market controls that are not 
provided to traders. Examples of such controls are broadcasting messages that 
appear on UTCs 120 and halting tradmg activity. 
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Three-Tier Architecture of the Preferred Embodiment 

The system of the present invention is designed to adapt to the needs of a 
variety of different types of trading markets. Operating on a wide range of 
hardware, from single-user personal computers (PCs) to integrated client/server 
based platforms, the system of the present invention is well suited to a small 
number of users and to a market with thousands of users. The system may be 
field-modified to handle an increasing number of users as market requirements 
mature and change. 

Figure 4 shows data flow of one embodiment of the invention. A market 
700 comprises an auction 7 10. Although a market may include a plurality of 
phases, only one phase is shown in operation 720. With respect to a plurality of 
phases, one skilled in the art will appreciate that an auction specification of one 
phase may be replaced with an auction specification of another phase by methods 
known in the art. A bid, submitted by a trader, is sent to the bid verifier at 
operation 730. The bid verifier determines whether the bid meets certain rules 
that are specified by a market designer or another party who may control an aspect 
of the auction. Thereafter, an admitted bid is sent to the bid transformer at 
operation 740. At this operation, the bid is modified to reflect discrimination 
policies wherein the bid may be increased, decreased, or some other modification 
in order to reflect a status that has been granted to that particular trader or to a 
particular good. At operation 750, the bid is processed wherein rules are applied 
to the accepted bids and the best bid prevails. Note that the best bid may not 
necessarily be the highest bid; rather, it is the bid that reflects the discrimination 
allocation policies that are applied. The bid is then submitted to the order book at 
operation 760. At this operation, tie breaking rules may be applied, sort criteria 
may be used, and any other criteria designated by the market designer may be 
implemented. At operation 770, the bid is submitted to the clearer wherein a 
clearing operation is applied. At operation 780, the bids are submitted to the 
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trade manager for further processing. Information manager is continuously 
operating and may be providing information to traders on a continuous basis at 
operation 790. 

Figure 5 shows one embodiment of the invention wherein a three-tiered - 
architecture supports scalability allowing other system architectures to be 
implemented. A first tier 1 10 includes a front-end database 1 12 and Web 
applications mnning on Web server(s) 111 that constitute the interface between 
the users 1 14 and the back-end 116 of the system* Authorized users may access 
the system through a Web browser. GUI may be mn either as a Java Applet or as 
a common HTML (depending on the user's choice and browser version). Java 
and HTML programming languages are well known to those of ordinary skill in 
the art. To secure the system, the Web application is surrounded by a firewall 122 
in a DMZ (Demilitarized 2^ne) configuration making it almost impossible to 
penetrate the application server(s) 120. The application's logic constitutes the 
second tier 115. The middleware 130 enviromnent is component-based allowing 
high-availability and scalability. The third tier 133 contams the database 136 and 
the interface 138 to a tnaricet administrator's legacy systems. Note that because 
the output of the auctioning process is being polled by a legacy system, the full 
security of the legacy environment is assured at all times. 

Thus, a method and apparatus for designing and deploying a universal, 
interactive, real-time, trading market system serving traders conununicating via 
the Internet is disclosed. Although the present invention has been described with 
reference to specific exemplary embodiments, it will be apparent to those of 
ordinary skill in the art that various modifications and augmentations may be 
made to these embodiments without departing from the broader spirit and scope 
of the present invention as set forth in the following claims. 
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CLAIMS 

We claim: 

1 . A universal auction system having a programmable auction server, the 
programmable auction server comprising: 

a plurality of auction modules wherein at least one auction module 

corresponds to at least one function of an auction selected &om the 
group consisting of a bid verifier, an information manager, a 
clearer, a registration manager, and a proxy bidder. 

2. The programmable auction server as in claim 1 , further comprising: 
auction modules wherein at least one auction specification module 

performs at least one transaction selected from the group comprising a bid 
verification transaction, an information management transaction, a clearing 
transaction, and a registration transaction. 

3. The programmable auction server as in claim 1, further comprising: 
a set of trading primitives; 

a script interpreter for interpreting a temporal protocol script representing 
an auction specification, the script including references to at least a 
portion of tiie set of trading primitives; and 

means for switching an auction specification of one phase with an auction 
specification of another phase. 

4. The programmable auction server as in claim 3 , wherein at least one 
auction module of one phase is replaced witii at least one auction module of 
another phase. 
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5. The progranunable auction server as in claim 1, at least one phase 
comprising an interval in which at least one transaction occurs, the transaction is 
selected from the group comprising submitting a bid, admitting a bid, 
withdrawing a bid, and replacing a bid. 

6. The programmable auction server as in claim 5, wherein the phase is 
temunated by a condition. 

7. The programmable auction server as in claim 6, wherein the condition is a 
time period. 

8. A universal auction system comprising: 

a trading primitive; 

a script generator for translating trading primitives to temporal 
protocol script; 

a script interpreter for interpreting script protocol; and 

a market specification console adapted to support a plurality of 

market protocols. 

9. The universal auction system as in claim 8, the market specification 
console fmther comprising a plurality of rules wherein at least one rule is user- 
modifiable. 

10. The universal auction system as in claim 9, wherein rules comprise market 
protocols. 

1 1. The universal auction system as in claim 8, wherein the market 
specification console is coupled to a programmable auction server wherein said 
programmable auction server is adapted to receive market protocols from said 
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market specification console, the market specification console having a graphic 
user interface (GUI). 

12. The universal auction system of claim 11, wherein a trader interface is 
coupled to a network. 

13. The universal auction system of claim 12, wherein the trader interface is 
used by a teader to submit a bid. 

14. A market specification console comprising: 
means for specifying a plurality of maricet protocols; 
means for displaying at least one market protocol; and 

means for transmitting at least one market protocol to a programmable 
auction server 

15. A method of designing a universal auction system comprising: 
generating a plurality of auction modules wherein at least one auction 

module corresponds to at least one function of an auction selected from the group 
comprising of a bid verifier, an information manager, a clearer, and a registration 
manager, 

specifying a plurality of rules wherein a transaction comprises at least one 
rule; and 

implementing at least one transaction comprising a bid verification, 
information dissemination, clearing, and registration of information. 

16. The method of claim 1 5 further comprising: 
displaying a rule to a market designer. 

17. The method of claim 1 5 further comprising: 
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modifying at least one rule. 

18. The method of claim 15 further comprising: 
interpreting a scripted rule. 

19. The method of claim 1 5 further comprising: 
generating a scripted rule. 

20. The method of claim 15 further comprising: 
transmitting a rule to a programmable auction server. 

21 . The method of claim 15 further comprising: 
maintaining a status of bids. 
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